SOAP originally stood for “Simple Object Access Protocol,” but over time, SOAP has developed away from merely accessing objects and toward a generalized extensible messaging framework. Although a popular network representation for SOAP is an XML-based protocol that is designed to exchange structured and typed information on the Web, SOAP can be used in combination with a variety of existing Internet protocols and formats and can support a wide range of applications from messaging systems to remote procedure calls (RPCs).
Simply put, SOAP defines a way to move messages from point A, such as a message sender 102, to point B, such as a message receiver 104. See FIG. 1. SOAP defines a model for processing individual, one-way messages. One can combine multiple messages into an overall message exchange. FIG. 1 illustrates a system 100 where a simple one-way message is sent by the message sender 102, and the message sender 102 does not require a response from the message receiver 104. The receiver 104 could, however, send a response back to the message sender 102. SOAP allows for any number of message exchange patterns, of which request/response is just one. Other examples include notifications, and long-running peer-to-peer conversations.
The SOAP messaging framework facilitates exchanging XML messages in heterogeneous environments where interoperability has long been a difficult problem to solve. The SOAP messaging framework defines a suite of XML elements for packaging arbitrary XML messages, such as the XML message 106, for transport between systems, such as the message sender 102 and the message receiver 104. The framework consists of a few core XML elements: envelope, header, and body.
The envelope element (described by a beginning tag 106A <SOAP:ENVELOPE> and its companion ending tag 106J </SOAP:ENVELOPE>) is always the root element of a SOAP message, such as a SOAP message 106. This makes it easy for the message sender 102 and the message receiver 104 to identify SOAP messages by simply looking at the name of the root element.
The envelope element contains an optional header element, which is described by a beginning tag 106C <SOAP:HEADER> and its companion ending tag 106E </SOAP:HEADER>. The header element, unlike the body element, is a generic container for control information. It may contain any number of elements from any name space (other than the SOAP name space). Elements placed in the header element are referred to as header blocks. As with other protocols, header blocks contain information that influences payload processing. Header blocks can also be annotated with a global SOAP attribute named mustUnderstand to indicate whether or not the receiver is required to understand the header before processing the message as well as other attributes.
The header element is followed by a mandatory body element, which is described by a beginning tag 106F <SOAP:BODY> and its companion ending tag 106H </SOAP:BODY>. The body element represents the message payload, and as a payload, the body element is a generic container that is capable of containing any number of elements from any name space. This is ultimately where data will be contained when the message sender 102 attempts to send such data embedded in the SOAP message 106 to the message receiver 104. This minimal design of header and body elements to respectively contain control and data information in a SOAP message helps to foster a simple architecture allowing heterogeneous environments to communicate. However, such a design also hinders the application of the SOAP protocol in data intensive communications. FIG. 1 illustrates this problem and other problems in greater detail.
Suppose that the message sender 102 is a personal digital assistant, which is a light-weight computer designed to provide specific functions like personal organization (calendar, note-taking, database, calculator, and so on) as well as communications. More advanced personal digital assistants also offer multimedia features, such as music playing. Many personal digital assistants rely on a pen or other pointing device for input instead of a keyboard or a mouse, although some offer a keyboard too small for touch typing to use in conjunction with a pen or pointing device. For data storage, a personal digital assistant relies on flash memory instead of power-hungry disk drives. Suppose also that the message receiver 104 is a pair of intelligent loudspeakers, which are devices that accept messages containing a digital encoding of sound and generate sounds loud enough to be heard by the user of the message receiver 104.
Consider a situation where the message sender 102 (a personal digital assistant that can play music) sends a song in digital audio form to the message receiver 104. Using the SOAP protocol, the message sender 102 inserts into the body element (described by tags 106F, 106H) ASCII data that represents the digital audio, which in turn represents the original song. Whereas digital audio is typically compressed using a coding scheme, such as MP3, to shrink the size of the digital audio file without seriously degrading the quality of the sound, ASCII is not a compressed scheme. While not a requirement, the vast majority of SOAP messages are exchanged as an XML/1.0 document which uses some text-oriented encoding, typically UTF-8 or UTF-16. Most digital audio files are compressed to average about three megabytes of data. The conversion of those digital audio files to a representation supported by XML/1.0 so that they can be embedded in SOAP messages would cause the size of SOAP messages to be prohibitively large.
However, even more important is the problem that if the data is included in the body element, then the data must be exchanged, in its entirety, before message processing at the receiver can begin. There are many situations in which this is undesirable. The receiver may not be able to process the data in the form supplied by the sender, and will request that the sender supply the data in a different form; if the data is included in the body of the message then the data will end up being sent twice. The receiver may not need all of data in the message; if the data is included in the body of the message then the receiver has no choice but to accept all of the data and discard the portions it does not need. Or a fault in the network may cause the message to be garbled after the bulk of it has been exchanged; if the data is included in the body of the message then there is no alternative to exchanging the message again, in its entirety. In all of these situations including the data in the body of the message results in needless consumption of network resources.
Large SOAP messages due to bulky pieces of data in the body element cause lackluster performance in the sending process, the transferring process, and the receiving process. While the SOAP protocol has helped to enable rich and automated Web services based on a shared and open Web infrastructure, SOAP messages were not designed originally for transferring bulky pieces of data, such as multimedia data. Without a solution to separate the control information in the header of a SOAP message from the data information in the body of the SOAP message, the SOAP protocol will be limited in its application, and users may eventually no longer trust the system 100 to provide a desired computing experience because of lackluster performance, causing demand for the system 100 to diminish from the marketplace. Thus, there is a need for a method and a system for sending information by reference while avoiding or reducing the foregoing and other problems associated with existing systems.